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ppnrpnp FT SYSTBMF- HE pn imiM AUTHRNTIFICATION 
gpr^TTPTgpp p'TTN TITILIS A TPITR T.QRS DF, TMCCES A UN SSRYICg 
PAP T 'nS |TP.RMEDIAIRF .r>'TTMRESEAUIP. 

5 

La prdsente invention conccme la foumiture de services bas6s sur un transport 
IP (Internet Protocol), tels que les services accessibles par I'intenn^diaire du 
r6seau Internet ou des services conversationnels sur IP. 

10 A rheure actuelle, lorsqu'un utilisateur souhaite acc^er h un tel service, il doit 
se connecter au r6seau IP par rinterm6diaire d»un r&eau d'accfes et d»un 
foumisseur de service (FS) tel qu*un foumisseur d'accte Internet. A cet effet, il 
doit pr^lablement 6tre aulhentifi6 par un serveur d'authentification du 
foumisseur de service. Pour cela, il doit lui transmettre un identifiant de la 

1 5 forme identifiantFS@domaineFS et un mot de passe. Une telle authentification 
permet au foumisseur de service de personnaUser ses services, par exemple en 
transmettant k I'utilisateur une page d'accueil dans laquelle figure le nom de 
Tutilisateur. 

20 Une fois que I'utilisateur est connects au r^seau Internet, il peut acc^der k 
d'autres services qui peuvent dgalement proposer une identification >et • 
authentification de I'utilisateur afin de pouvoir lui ofifrir des services k forte 
valeur ajout^e. Par exemple, un service de banque en ligne sur Internet n6cessit^ 
un op6rateur de r&eau d'acc^, un foumisseur d'accfes k Internet et la banque 

25 concem6e. Un acc^ k un r&eau Intranet d*entreprise n6cessite au moins un 
op6rateur de r&eau d*accfes et 1' entreprise concern^. 

Plusieurs authentiifications peuvent done 6tre effectu^es durant une m6me 
connexion. Comme ces authentifications sont r6alis6es par des acteurs difKrents 
30 du r&eau, elles sont effectu6es d'une manifere ind€pendante, ce qui oblige 
I'utilisateur ex6cuter plusieurs procedures d'authentification. L'ergonomie 
ainsi offerte k I'utilisateur apparait done mediocre, et fastidieuse. 

Par ailleurs, il s'av^re que les procedures d'authentification utilis^es 
35 actuellement par les fouraisseurs de services et qui sont bashes sur la foumiture 
d'un identifiant et d'un mot de passe, offrent une s6curit6 m6diocre, et en tout 
cas, insuffisante pour permettre k un acteur de jouer le rdle de tiers de confiance 
vis-i-vis d'autres foumisseurs de services. 
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Dans le cas de r6seaux d*accfes, les procedures d'authentification actuelles qui 
sont ex^cut^es durant les connexions IP/PPP (Point-to-Point Protocol) via un 
r6seau RTC (Roseau Tei^phonique Commute), RNIS (Roseau Num^rique & 
5 Integration de Services) oii I'ADSL (Asymmetric Digital Subscriber Line), ne 
permettent pas d'effectuer une authentification au niveau du r^seau d'accds 
pour les connexion PPP. Generalement, rop^rateur de r6seau ORA/OTI 
(Op^rateur de R6seaux d*Acc6s / de Transport IP) ne peut pas utiliser les 
informations transmises par I'utilisateur pour 6tre authentifi6 auprfes du 
1 0 foumisseur de service, dans le but dMdentifier I'utilisateur, car il ne mattrise pas 
ces informations qui sont gardes par un autre domaine administratif. 

II existe par ailleurs une procedure d*authentification securis^e bas^e sur un 
mecanisme de d^fi / r6ponse (Challenge / Response) qui a 6t6 normalis^e par 
15 exemple par le protocole CHAP (Challenge Handshake Authentication 
Protocol). Toutefois, cette procedure est congue pour effectuer une 
authentification securisde vis-i-vis d'un seul acteur independent, et doit done 
6tre executee k nouveau pour chaque acteur auprte duquel une authentification 
est souhaitee. 

20 

La presente invention a pour but de supprimer ces mconvenients en proposant 
un precede permettant d'effectuer une authentification pour plusieurs acteurs 
independants du reseau. Get objectif est atteint par la prevision d'un precede 
d*authentification d'un utilisateur lors d'une tentative d'accds h un acteur d'un 
25 reseau de transport IP, ce precede comprenant des etapes au cours desquelles : 

- un terminal d'utilisateur emet k un acteur du reseau une requ6te d'accds 

contenant des donnees d'identification et d'authentification de i'utilisateur 

aupres de I'acteur, la requite d'accds etant transmise par I'intermediaire d'un 

30 reseau d'accds et d'un reseau de transport IP i un serveur d'authentification 
de I'acteur, 

- le serveur d'authentification execute une procedure d'authentification de 
I'utilisateur sur la base des donnees d'identification et d'authentification 
contenues dans la requ6te d'accSs, et 

35 - le serveur d'authentification transmet au terminal d'utilisateur un message de 
reponse contenant le resultat de I'authentification de I'utilisateur par le 
servc-ur d'niitiientification. 
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Selon r invention, ce proc6d6 comprend en outre des 6tapes au cows 
desquelles : 

- un nombre al6atoire est transmis au tenninal pr^alablement k remission de la 
5 requite d'accfes, 

- des donn^es d'authentification de Putilisateur aupr^ d*au moins deux 
acteurs du r^seau sont calcuI6es k I'aide d*au moins un algorithme 
cryptographique pr^6fini et d*au moins une c\6 secrete propre h Tutilisateur, 

_ le terminal ins&re dans la requdte d*accds des donn6es d*identification de 
1 0 Tutilisateur auprds desdits acteurs du r^eau et les donn6es d*autfientification 
calcul6es, et 

- le tmninal transmet la requite d'acc6s k un contrdleur d'accte qui transmet h 
cliacun des deux acteurs une requite d*audientification respective contenant 
respectivement les donn6es d*identification et d'authentification de 

15 Tutilisateur auprds desdits acteurs du r6seau, contenues dans la requ6te 
d'acc&s, 

- des serveurs d'authentification de chacun des acteurs ex^cutent une 
procedure d'authentification de Tutilisateur, sur la base des donn6es 
d'identification et d'authentification de I'utilisateur, contenues dans les 

20 requStes d'authentification, et 

- des comptes rendus d'authentification contenant des r^sultats des procedures 
d'authentification ex6cut6es par les serveurs d'authentification de chacun 
desdits acteurs du r6seau sont transmises au terminal. 

25 Avantageusement, au moins Tune des dorm^ d'authentification est calcul^e 
par un module connects au terminal. 

Selon un mode de realisation de I'invention, ce proc6d€ comprend une etape 
pr^alable au covas de laquelle le terminal etablit une connexion avec im serveur 
30 specialise par I'intermediaire du reseau, le nombre aieatoire etant genere et 
transmis au terminal par le serveur specialise k la suite de retablissement de la 
conn^on. 

Selon un autre mode de realisation de I'invention, la requdte d'acc^s emise par 
35 le terminal est transmise au serveur specialise qui y insure le nombre al6atoire 
utilise pour calculer les doimees d'authentification, la requdte d'acc^s etant 
ensuite transmise au controleur d'acces qui insere le nombre aieatoire dans les 
requ6tes d'authentification transmises aux deux acteurs. 
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Selon encore un autre mode de realisation de i'invention, les procedures 
d*authentification ex6cutees par les serveurs d'authentification des acteurs 
comprennent une etape de recherche de la cl6 secrete de Putilisateur sur la base 
5 de la donn6e d'identification contenue dans la requSte d*authentification, une 
etape de calcul d'une donn6e d*authentification en executant l*algorithme 
cryptographique avec la cl6 secrete de I'utilisateur et le nombre al^atoire 
contenu dans la requdte d'authentification, et une etape de comparaison de la 
donn^e d'authentification contenue dans la requdte d'authentification, avec la 
1 0 donn^e d'authentification calcul^e, I'utilisateur 6tant correctement authentifie si 
la donn6e d'authentification contenue dans la requdte d'authentification 
correspond k la donn6e d'authentification calcul6e. 

Selon encore un autre mode de realisation de I'invention, les acteurs du rdseau 
15 comprennent plusieurs acteurs paimi des foumisseurs d'acc&s of&ant i 
Tutilisateur un acc6s au r&eau Internet, des foumisseurs de service DP, et un 
operateur de r^seau d'acc^s et de transport IP. 

Avantageusement, les donn6es d'identification ins^rees dans la requite d'accds 
20 sont de la forme : 

"IdA@DomaineA" 

dans laquelle : 

- "IdA" represente I'identifiant de I'utilisateur auprds de I'acteur du r&eau, 
25 - "DomaineA" repr&ente I'identifiant de I'acteur du r&eau dans le r&eau de 
transport IP, 

le contrdleur d'accds determinant les acteurs vers lesquels transmettre les 
requStes d'authentification sur la base des identifiants "DomaineA" de I'acteur 
du reseau contenus dans la requdte d'acc^s. 

30 

Avantageusement, les etapes d'authentification de I'utilisateur par les serveurs 
d'authentification des acteuns sont effectuees Tune k la suite de I'autre. 

Altemativement, les etapes d'authentification de I'utilisateur par les serveurs 
35 d'authentification des acteurs sont declenchees sensiblement simultanement 

De preference, le nombre tjleatoire \ nartir duquel les donndcr; 
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tentative de connexion. 

Selon encore un autre mode de realisation de IMnvention. les procedures 
d'authentification de rutilisateur sont effectu^es conformement au protocole 
5 CHAP. 

LMnvention conceme 6galement un systdme d'authentification d'un utilisateur 
lors d'une tentative d'acc^s h un acteur d'un r&eau de transport IP auquel sont 
connectes des acteurs du r^seau, et auquel des terminaux d'utilisateurs peuvent 
10 acc6der par I'intermediaire de rfeeaux d'accte, ce systdme comprenant : 

_ des moyens pr6vus dans chaque terminal d'utilisateur pour 6mettre des 
requetes d'accfes k un acteur du r^seau, ces requites contenant des donn6es 
d'identification et d'authentification de rutilisateur auprfes de I'acteur du 
15 r^seau, et 

- au moins un serveur d'authentification pour chacun des acteurs du r^seau, 
con^u pour identifier et authentifier les utilisateurs en fonction des donn6es 
d'identification et d'autiientification contenues dans les requStes d'accds 



refues. 



20 



Selon I'invention, chaque terminal d'utilisateur comprend des moyens pour 
recevoir un nombre al6atoire lors de l'6tablissement d'une connexion avec le 
r6seau de transport IP, des moyens de calculs cryptographiques pour appliquer 
au moins un algoritimie cryptographique pr6d6fini au nombre al^atoire recu afin 
25 d'obtenir des donn6es d'autiientification de I'utilisateur aupr^s d'au moins deux 
acteurs du r^seau, et des moyens pour insurer dans chaque requite d'accds 
6mise des donn^es d'identification de I'utilisateur auprte des deux acteurs du 
r^seau et les donn6es d'autiientification calculdes, le systfeme comportant en 
outre un contrdleur d'acc^s comprenant des moyens pour recevoir les requ6tes 
30 d'accis provenant des terminaux d'utilisateurs et transmises par le r6seau de 
transport IP, des moyens pour extraire de chacune des requStes d'accfes les 
donntes d'identification et d'authentification de I'utilisateur auprds d'au moins 
deux acteurs du r6seau, des moyens pour transmettre k chacun des deux acteurs 
une requSte d'autiientification respective contenant respectivement les donn6es 
35 d'identification et d'autiientification de I'utiHsateur auprds des deux acteurs, 
cont^ues dans la requSte d'accds. i 
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Selon un mode de realisation de l*invention, ce syst6me compimd un module 
exteme con9u pour se comiecter k chacun des terminaux d'utilisateuis et 
comprenant des moyens pour recevoir le nombre al6atoire du temiinal auquel il 
est comiecte, des moyens de calcul cryptographique pour ex6cuter Talgorithme 
5 cryptographique pr6d6fini sur la base du nombre al^toire, et pour transmettre 
au terminal au moins une donn6e d'authentification de Tutilisateur auprds d'un 
acteur du r6seau obtenue par les calculs cryptographiques. 

Avantageusement, I'algorithme pr^d^fini est un algorithme cryptographique 
1 0 utilisant une cU secrfete propre h I'utilisateur et m^moris^e par le module. 

Selon un autre mode de r&Usation de rinvention, le module est une carte h 
microprocesseur, chaque terminal comportant des moyens pour se connecter k 
une carte k microprocesseur. 

15 

Selon un autre mode de realisation de I'invention, le contrdleur d'acc^s 
comprend en outre des moyens pour recevoir des comptes rendus 
d'authentification de I'utilisateur, ^mis par les acteurs en r^onse aux requ6tes 
d'authentification, et des moyens pour transmettre au terminal d'utilisateur un 
20 compte rendu d'authentification sur la base des comptes rendus refus des 
acteurs. 

Selon encore un autre mode de realisation de I'invention, ce systSme comprend 
en ouU-e un serveur specialise connecte au reseau de manidre k 6tre connecte 
25 aux terminaux d'utilisateurs it. la suite de I'etablissement d'une connexion du 
terminal au reseau, le serveur specialise comprenant des moyens pour generer et 
transmettre un nombre aieatoire k chacun des terminaux avec lesquels une 
connexion est etablie, et des moyens pour inserer le nombre aieatoire dans 
chacune des requdtes d'acces emises par les terminaux. 

30 

De preference, le serveur specialise est un serveur HTTP comportant une 
int^ace avec le protocole RADIUS. 

Egalement de preference, le contr6Ieur d'accfes est un Proxy RADIUS 

35 

Selon encore un autre mode de realisation de I'invention, chaque acteur du 
rir.eov oomprc-nd ths- moyens de eiockaaz dc- c!ir> jccriieij il"ui.ili3ateuf2. d-: 



-7- 

ractcur en appliquant au nombre al6atoire re9U dans unc requite 
d'authentification et h la d6 secrete d*un utilisateur ralgorithme pr6d6fini, et 
pour comparer le r^sultat obtenu h la donn^e d'authentification de rutilisateur 
refue dans la requ6te d'authentification, l*utilisateur 6tant coirectement 
5 authentifi6 par Tacteur uniquement si le r&ultat du calcul cryptographique 
obtenu est 6gal k la donn^e d'authentification contenue dans la requite 
d'authentification. 

Un mode de realisation pr6f(£r6 de I'invention sera d6crit ci-apr6s, k titre 
1 0 d'exemple non limitatif, avec r^fSrence aux dessins annexes dans lesquels : 

La figure 1 repr^sente sch6matiquement I'architecture d'un 
systfcme de foumiture de services bas&i sur un transport IP, selon 
I'invration ; 

^5 La figure 2 repr6sente un diagramme de s6quenc€ment d'^apes 

qui sont ex^cut^es dans le systfeme represents sur la figure 1, 
conformdment au precede selon V invention. 

Le systeme represente sur la figure 1 comprend des rSseaux d'accfes 1, 2 
auxquels sont connectes des terminaux 11 d'utilisateurs. Ces reseaux d'acc^s 1, 
20 2 foumissent aux terminaux 11 un accfes k un rSseau de transport IP 5 par 
I'intermediaire de passerelles IP 3, 4 respectives adaptees au reseau d'accds. 
L'ensemble des reseaux d'accfes, des passerelles et du reseau de transport IP est 
mis en oeuvre par un operateur ORA/OTI de reseaux d'accfes et de transport IP. 

25 Le reseau de transport IP 5 permet aux utilisateurs d'acceder k un foumisseur 
d'accfes Internet 6, 7 ou un foumisseur de services IP 8. 

A cet effet, ce systeme comprend, selon Tinvention, un serveur specialise 12 
qui deiivre aux utilisateurs souhaitant se connecter au rSseau IP, des nombres 
30 aieatoires destines k gtre utilises au cours de procedures d'identification, et un 
contrdleur d'accfes 10 connecte au reseau de transport IP 5 et auquel le serveur 
specialise 12 transmet les requites d'accfes emises par les terminaux 11. 

Le contrdleur d'acc^s 10 est con9u pour recevoir toutes les requetes d'accds k 
35 un foumisseur 6, 7, 8 d'accds ou de service, emises par les utilisateurs sur les 
reseaux 1, 2, par I'intermediaire de la passerelle 3, 4 correspondant au reseau 
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d*acc6s 1, 2 employ^, et du serveur sp6cialis6 12, et d'aiguiller ces requates au 
travers du r6seau de transport IP vers le foumisseur 6, 7, 8 d'accds ou de service 
indiqu6 dans la requdte par le terminal de Tutilisateur. 

5 II est h noter que les passerelles 3, 4 peuvent altemativement assurer les 
fonctions ex^cut6es par le serveur spdcialis^ 12. 

Pour acc6der au r^eau IP 5 par rinterm6diaire d'un foumisseur d'acc^s 6, 7 et 
i un service particulier offert par un foumisseur de service 8 connects au 

10 r€seau, le terminal de PutiUsateur execute tout d'abord une procedure 
d*6tablissement de connexion avec le serveur sp6cialis6 12 pour obtenir un 
nombre aliatoire RAND. Ensuite, le terminal de I'utilisateur 6met une requdte 
d*acc^ au foumisseur de service souhait6 via le foumisseur d'accte, qui est 
transmise successivement par la passerelle IP 3, 4 et par le serveur sp^ialis6 12 

15 au contrdleur d'accfes 10. A la reception d*un& telle requite, le contrdleur 
d'accds 10 demande au foumisseur d'acc6s 6, 7 et au foumisseur de service 8 
demand6s d'authentifier I'utilisateur. Loisque le foumisseur d'accds et le 
foumisseur de service ont envoy6 leur r6ponse concemant I'authentification de 
Putilisateur, le contrdleur d'accSs ^met une r^ponse d*autorisation d'accds k 

20 destination du terminal 11 de Putilisateur, en fonction des r^onses 
d'authentification re9ues. 

Le s^quencement des Stapes du proc6d6 d'authentification selon I'invention est 
illustr6 par le diagrammerepr6sent6 sur la figure 2. 

25 

Pour acc6der k un service IP, ie terminal 1 1 de I'utilisateur execute tout d'abord 
une procedure 21 d'6tablissement d'une connexion avec le serveur sp6cialis^ 12 
via une passerelle IP 3, 4 accessible au terminal, I'adresse du serveur sp6cialis6 
6tant par exemple connue du logiciel de connexion install^ dans le terminal. 
30 Cette procedure consiste tout d'abord k 6tablir une connexion avec la passerelle 
IP 3, 4, par exemple conform^ent au protocole LCP (Link Control Protocol). 
Juste apr^s I'ouverture de la connexion, un nombre al6atoire RAND est envoy6 
par le serveur sp6cialis6 12 au terminal 11 (6tape 22), par exemple sous la 
forme d'un message de d^fi 41 conforme au protocole CHAP. 

35 

Ce nombre aleatoire est destind a servir de base h des calculs de mots de passe 

utiH."Gbles uniquansnt pour la tentstivc dc connexion et d'accif: -n c.-'ur;. Ce2. 
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cryptographie faisant intervenir une ou plusieurs cl^s secretes et le nombre 
al^atoire RAND foumi par le serveur sp^ialis^ pour la connexion en cours. Les 
algorithmes cryptographiques peuvent 6tre mis en oeuvre par le terminal de 
rutilisateur, et/ou de pr6f<6rence par un module 15 physiquemcnt ind^endant 
5 de ce dernier, par exemple de type carte k microprocesseur. 

Dans ce dernier cas, le logiciel de connexion install6 dans le terminal est en 
outre con9U pour interroger le module IS. 

10 L*algorithme de cryptographic choisi est par exemple celui qui est impl^ment^ 
dans les cartes SIM (Subscriber Identification Module) des terminaux mobiles 
de type GSM (Global System for Mobile communications). 

A la reception du message de d6fi 41, le terminal en extrait le nombre al^atoire 
1 5 RAND 42 et le transmet au module 1 5 connect^ au terminal (6tape 23). 

A l'6tape suivante 24, le module 15 applique un algorithme de cryptographic au 
nombre al6atoire re9u en utilisant une cl6 secrete de I'utilisateur, ce qui permet 
d*obtenir un nombre 43 k utiliser comme mot de passe d'authentification de 

20 I'utilisateur. Pour acc6der h plusieurs acteurs du r^seau choisis par Tutilisateur, 
d. savoir par exemple un foumisseur d*accte et un foumisseur de service, autant 
de mots de passe que d'acteurs k acc6der sont de pr6f<5rence g6ndr& par le 
terminal et/ou par le module 15, avec le m6me algorithme cryptographique op 
avec des algorithmes diffdrents, et avec la mfime cl6 secrfete ou avec des cl6s 

25 secretes diffdrentes. Les mots de passe AUTHl, AUTH2 .dventuellement 
calculus par le module IS sont ensuite transmis en rdponse au terminal 1 1. 

Bien entendu, si I'un ou les deux algorithmes cryptographiques sont install6s 
dans le terminal, Tdtape 24 est au moins partiellement ex6cut6e par le termmal. 

30 

Une fois la connexion avec le serveur sp6cialis6 12 6tablie, le terminal envoie 
un message 44 de requ6te d'acc&s k celui-ci (6tape 25). Ce message de requdte 
44 comprend les identifiants IDl et ID2 de I'utilisateur respectivement aupres 
du foumisseur d'acc^ et du service choisi, et les mots de passe AUTHl et 
35 AUTH2 obtenus par les calculs cryptographiques. 

A la reception du message de requSte 44, le serveur sp6cialis6 12 encapsule ce 
message dans une requ6te d'autorisation d'accfes 45 (^tape 26). Cette requite est 
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par exemple du type "Access-Request" confoime au protocole RADIUS 
(Remote Authentication Dial In User Service) comportant un attribut nom 
d'utilisateur "User-Name" 6gal aux deux identifiants concat^nfe ID1|ID2, un 
attribut mot de passe "CHAP-Password" 6gal aux deux mots de passe 
6 concat6n6s AUTH1|AUTH2, ainsi qu'un attribut "CHAP-Challenge" destine h 
recevoir le nombre al6atoire RAND utilise pour g^n^rer les mots de passe, le 
nombre RAND 6tant d^termin6 par le serveur sp6cialis6 en fonction d'un 
identifiant de la session de connexion en cours avec le tenninal. La requ6te 45 
est transmise par le serveur sp6cialis6 12 au contrdleur d'accds 10. 

10 

A r^tape 27 suivante, le contrdleur d»acc6s re9oit la requSte 45 et en extrait les 
paramfetres d'identification et d*authentification. Ces paramdtres sont transmis 
aux stapes 28, 29 dans des messages d»authentification 46, 47 respectivement 
aux serveurs d*authentification 16 du foumisseur d'accds et du foumisseur de 

1 5 service choisi. Les informations d'identification IDl et ID2 sont par exemple de 
la forme "IdA@domaineA", "IdA" permettant d'identifier d'une manidre 
unique Putilisateur auprds du foumisseur d'accis ou de service, et "domaineA" 
permettant de determiner le nom de domaine dans le r^seau IP, du serveur vers 
lequel doit 6tre envoys le message d*authentification correspondent. Ces 

20 messages d'authentification 46, 47 contiennent chacun Tidentifiant et le mot de 
passe correspondant au destinataire du message, ainsi que le nombre al6atoire 
RAND, 

A la reception d'un tel message d'authentification 46, 47, le serveur 
25 d'authentification 16 execute une procedure d'authentification 28, 
respectivement 29. Cette procedure d'authentification consiste k identifier 
I'utilisateur grSce a I'information d'identification IDl, respectivement ED 2, 
puis h determiner la cI6 secrete de I'utilisateur en acc^dant k une base de 
dorni^es de cl6s secrMes d'utilisateurs autoris6s, h calculer ensuite le mot de 
30 passe de I'utilisateur k I'aide de cette cl<5 secrfete et du nombre RAND re9u, et 
enfin k comparer le mot de passe ainsi calcul6e avec celui qui a 6t& refu. Pour 
calculer le mot de passe AUTH, le serveur d'authentification dispose du mSme 
algorithme cryptographique que celui utilise par le terminal 1 1 ou le module 15. 

35 L'utilisateur est correctement authentifie uniquement si le mot de passe calcuie 
par le serveur d'authentification est identique k celui qui aet6 re9u. 
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contrdleur d'accte 10 sous la forme d'un message 48, respectivement 49 de 
compte-iendu d*authehtification. 

A la reception des deux messages 48, 49 de compte-rendu d'authentification. en 
5 provenance respectivement du foumisseur d'accSs 6. 7 et du foumisseur de 
service IP 8 choisi, le contrdleur d'accds 10 dispose des informations 
n^cessaires pour g6rer les droits d'acc^s de I'utilisateur en fonction de la 
politique de l»op6rateur ORA/OTI et execute une 6tape 30 de gdn6ration d»un 
message 50 de r^ponse h la requdte d'accds 6mise par rutilisateur et transmet ce 
1 0 message de r^ponse au serveur sp6cialis6 12. 

Ce message de r6ponse 50 contient les comptes-rendus d'authentification 6aas 
par le foumisseur d»accte 6, 7, et par le foumisseur de service 8 choisi. 

15 n est a noter que les procedures d'authentification 28 et 29 ex6cut6es par le 
foumisseur d'accfcs 6, 7 et le foumisseur de service 8 peuvent etre ex6cut6es 
sunultandment ou bien s6quentiellement dans un ordre quelconque. 

A la reception du message de r6ponse 50, le serveur sp6cialis6 12 ex^ute une 
20 procedure 3 1 consistent k extfaire de ce message de r6ponse les informations k 
renvoyer h I'utilisateur, puis h transmettre au terminal d'utilisateur dans un 
message 51. par exemple de type "CHAP-success" ou "Chap-failure" pour le 
protocole CHAP, les informations extraites qui lui sont destin6es. 

25 Grace h. ces dispositions, un utilisateur pent 6tre authentifi6 shnultan&nent par 
diff^rents acteurs du r6seau, par exemple b6n6ficier d'un accds k Intemet dans 
lequel U a €t& authentifi6 par un service de paiement en ligne s6curis6, par 
exemple offert par un organisme bancaire. n pent en outre dtre authentifi6 par 
rop6rateur ORA/OTI. 

30 

L'invention qui vient d'fitre d6crite peut 6tre r6alis6e en mettant en oeuvre un 
serveur sp6ciaUs6 12 du type serveur HTTP, et un contrdleur d'accte 10 du type 
proxy B^ADIUS, le serveur sp6cialis6 comportant une interface RADIUS pour 
pouvoir communiquer avec le contrdleur d'accfes, les serveurs d'authentification 
35 6tant 6galement des serveurs RADIUS. 
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REVENDICATIONS 

1. Proc^d^ d'authentification d'un utilisateur lors d*une tentative 
d»acc^ h un acteur (6, 7, 8) d*un r^seau de transport IP (5), ce proc^d^ 
5 comprenant des 6tapes au cours desquelles : 

- un terminal (1 1) d'utilisateur ^met h. un acteur du r^eau (5) une requfite 
d'accds (44) contenant des donn^es dMdentification et d'authentification de 
I'utilisateur auprfes de I'acteur, la requite d'accds 6tant transmise par 
i'intenn^diaire d'un r6seau d*accds (1, 2) et d'un r&eau de transport IP (5) h 

10 un serveur d'authentification (16) de I'acteur, 

- le serveur d'authentification ex^ute une proc^ure d'authentification (28) de 
I'utilisateur sur la base des donn^es d'identification et d'authentification 
contenues dans la requ6te d'acc6s, et 

- le serveur d'authentification (16) transmet au terminal (11) d'utilisateur un 
15 message de r^onse (51) contenant le r^ultat de Tauthentificadon de 

Tutilisateur par le serveur d'authentification (16), 
caract^ris6 en ce qu'il comprend en outre des Stapes au cours desquelles : 

- un nombre al6atoire est transmis au terminal (1 1) pr^alablement i remission 
de la requite d'accds (44), 

20 - des donn^es d'authentification de I'utilisateur aupr^ d'au moins deux 
acteurs (6, 7, 8) du r^seau (5) sont calcul6es k I'aide d'au moins un 
algorithme cryptographique pr6d6fini et d'au moins une cl6 secrete propre h 
I'utilisateur, 

- le terminal (11) insdre dans la requ6te d'accds (44) des donn^es 
25 d'identification de I'utiUsateur auprds desdits acteurs du r&eau (5) et les 

donn^es d'authentification calcul^es, et 

- le terminal (1 1) transmet la requfite d'accds k un contrdleur d'acc^s (10) qui 
transmet k chacun des deux acteurs ime requSte d'authentification (46, 47) 
respective contenant respectivement les donn^ d'identification et 

30 d'authentification de I'utilisateur auprte desdits acteure du r^seau (5), 
contenues dans la requ8te d'accds, 

- des serveurs d'authentification (16) de chacun des acteurs ex^cutent une 
procedure d'authentification (28, 29) de I'utilisateur, sur la base des donn^es 
d'identification et d'authentification de I'utilisateur, contenues dans les 

35 requates d'authentification (46, 47), et 

- des comptes rendus d'authentification contenant des resultats des procedures 
d'authentification e:;scutees par len -^Qn'mrz d'oulJisntlficstion (16) di 



1191 UOpWi 



-13- 

2. Proc^d^ selon la revendication 1, 

caract6ris6 en ce qu'au moins I'une des doim6es d'authentification est calcul6e 
par un module (1 5) connects au terminal (1 1). 

5 

3. Proc6d6 selon la revendication 1 ou 2, 

caract6ris6 en ce qu'il comprend une 6tape pr^alable au cours de laquelle le 
terminal 6tablit une connexion avec un serveur sp6cialis6 (12) par 
I'interm^diaire du r6seau (5), le nombre al6atoire ^tant g6n6r6 et transmis au 
10 terminal (11) par le serveur sp6cialis6 k la suite de r^tablissement de la 
connexion. 

4. Proc6d6 selon la revaidication 3, 

caract6ris6 en ce que la requfite d'accte (44) 6mise par le terminal est transmise 
1 5 au serveur spteialis^ (12) qui y insure le nombre al6atoire utilise pour calculer 
les donn^es d'authentification, la requ6te d'accfes 6tant ensuite transmise au 
contrdleur d'accfes (10) qui insure le nombre al^atoire dans les requetes 
d*authcntification transmises aux deux acteurs (6, 7, 8). 

20 5. Proc6d6 selon la revendication 4, 

caract6ris6 en ce que les procedures d'authentification ex6cut6es par les 
serveurs d'authentification (16) des acteurs (6, 7, 8) comprennent une ^ape ^e 
recherche de la cl6 secrete de I'utilisateur sur la base de la donn^e 
d'identification contenue dans la requSte d'authentification, une dtape de calcul 

25 d'une donn6e d'authentification en executant I'algorithme cryptographique avec 
la cl6 secr^ de I'utilisateur et le nombre al6atoire contenu dans la requite 
d'authentification, et une 6tape de comparaison de la donnde d'authentification 
contenue dans la requfete d'authentification, avec la donn6e d'authentification 
calculde, I'utilisateur €tmt correctement authentifi6 si la donn^e 

30 d'authentification contenue dans la requfete d'authentification correspond k la 
donn6e d'authentification calculde. 

6. Proc6d6 selon Tune des revendications 1^5, 
caract&is6 en ce que les acteurs (6, 1, 8) du r^seau (5) comprennent plusieurs 
35 acteurs panni des foumisseurs d'accds (6, 7) of&ant k I'utilisateur un accfes au 
r&eau Internet, des foumisseurs de service (8) IP, et un op6rateur de reseau 
d'accte et de transport IP. 
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7. Proc6d6 selon Tune des revendications 1 i 6, 

caract^ris^ en ce que les donn6es d' identification insdr^es dans la requfite 
d*acc^ (44) sont de la forme : 

5 "IdA@DomaineA" 
dans laquelle : 

- "IdA" repr6sente Tidentifiant de I'utilisateur auprds de racteur du r&eau, 

- 'DomaineA" rq)r6sente IMdentifiant de I'acteur du r^seau dans le r^seau de 
transport IP (5), 

10 le contrdleur d'accds (10) ddterniinant les acteurs vers lesquels transmettre les 
requites d'authentification (46, 47) sur la base des identifiants "DomaineA" de 
Tacteur du r6seau contenus dans la requite d'accds (44). 

8. Proc^^ selon I'une des revendications 1 k 7, 

1 5 caract6ris6 en ce que les ^apes d'authentification (28, 29) de Tutilisateur par les 
serveurs d'authentification (16) des deux acteurs (6, 7, 8) sont effectu^es I'une h 
la suite de Tautre. 



9. Proc6d6 selon Tune des revendications 1^7, 
20 caract6ris6 en ce que les 6tapes d'authentification (28, 29) de I'utilisateur par les 
serveurs d'authentification (16) des deux acteurs (6, 7, 8) sont d^clench^es 
sensiblement simultan6ment. 



10. Proc^d6 selon Tune des revendications 1^9, 

25 caract6ris6 en ce que le nombre al^atoire k partir duquel les donn6es 
d'authentification sont calcul^es est un nombre al^oire modifi^ d chaque 
tentative de connexion. 

11. Proc6d6 selon I'une des revendications 1 d 10, 

30 caract6ris6 en ce que les procedures d'authentification de I'utilisateur sont 
effectu^es conform^ment au protocole CHAP. 

12. Systdme d'authentification d'un utilisateur lors d'une tentative 
d'accfes k un acteur (6, 7, 8) d'un r6seau de transport IP (5) auquel sont 

35 connect^s des acteurs du r^seau, et auquel des terminaux d'utilisateurs peuvent 
acc6der par I'interm^diaire de r^seaux d'acces (1. 2), ce systeme comprenant : 
- des iiioye-ns prd^us dans chaque tei-minal d' utilisateur pour imcttrs 
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donn^es d*identification et d'authentification de Tutilisateur auprds de 
Tacteur du r^eau, et 
- au moins un serveur d*authentification (16) pour chacim des acteurs du 
r6seau, con^u pour identifier et autfaentifier les utilisateurs en fonction des 
5 donn(6es d*identification et d*authentification contenues dans les requites 
d'accte re9ues, 

caractdris6 en ce que chaque terminal (11) d'utilisateur comprend des moyens 
pour recevoir un nombre al^atoire lors de l*6tablissement d*une c(»mexion avec 
le r^seau de transport IP (5), des moyens de calculs cryptographiques pour 

10 appliquer au moins un algorithme ciyptographique pr^6fini au nombre 
altetoire re^u afm d*obtenir des donn^es d'authentification de I'utilisateur 
auprds d'au moins deux acteurs du r^seau (5), et des moyens pour insurer dans 
chaque requ6te d'accfes (44) 6mise des donn6es d'identification de Tutilisateur 
aupr^ss des deux acteurs du r6seau et les donn^es d'authentification calcul^es, le 

15 syst^me comportant en outre un contrdleur d*acc^s (10) comprenant des 
moyens pour recevoir les requfites d'acc^s provenant des terminaux 
d'utilisateurs et transmises par le r^seau de transport IP (5), des moyens pour 
extraire de chacune des requ€tes d'accfes les donn6es dMdentification et 
d'authentification de Putilisateur auprds d'au moins deux acteurs du r^seau, des 

20 moyens pour transmettre h chacun des deux acteurs une requite 
d'authentification (46, 47) respective contenant respectivement les donn^es 
d'identification et d'auth^fication de Tutilisateur auprds des deux actei«rs, 
contenues dans la requite d*acc^ (44). 

25 13. Syst^e selon larevendication 12, 

caract^ris^ en ce qu'il comprend un module exteme (15) con9u pour se 
connecter k chacun des terminaux (11) d'utilisateurs et comprenant des moyens 
pour recevoir le nombre al6atoire du terminal auquel il est connects, des 
moyens de calcul cryptographique pour ex^cuter Talgorithme cryptographique 

30 pr^defini sur la base du nombre al6atoire, et pour transmettre au terminal au 
moins une donn^e d'authentification de I'utilisateur aupr&s d'xm acteur (6, 7, 8) 
du r^seau (5) obtenue par les calculs cryptographiques. 

14. Systfeme selon larevendication 13, 

35 caract^6 en ce que Talgorithme pr6d6fini est im algorithme cryptographique 
utilisant une cl€ secr^ste propre k Tutilisateur et m^orisde par le module (15). 

15. Syst^e selon larevendication 13 ou 14, 
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caract^ris6 en ce que le module (15) est une carte h microprocesseur, chaque 
terminal (11) comportant des moyens pour se connecter k une carte k 
microprocesseur. 

5 16. Syst^me selon IHme des revendications 12 i 1 5, 

caract6ris6 en ce que le contrdleur d*acc^ (10) comprend en outre des moyens 
pour recevoir des comptes rendus d*authentification (48, 49) de i*utilisateur, 
6mis par les acteurs en r^ponse aux requites d'authentification, et des moyens 
pour transmettre au terminal d'utilisateur un compte rendu d*authentification 

10 (51) sur la base des comptes r^dus re^us des acteurs. 

17. Systfcme selon Tune des revendications 12 h 16, 

caract6ris6 en ce qu'il comprend en outre un serveur sp€cialis6 (12) connects au 
r6seau (5) de manifere k 6tre connects aux terminaux (1 1) d'utilisateurs k la suite 
15 de r^tablissement d'une connexion du terminal au r6seau, le serveur sp6cialis6 
comprenant des moyens pour g6n6rer et transmettre im nombre al6atoire k 
ciiacun des terminaux avec lesquels une connexion est 6tablie, et des moyens 
pour insurer le nombre al^atoire dans chacune des requStes d'accds 6mises par 
les terminaux. 

20 

18. Systdme selon la revendication 17, 

caract6ris6 en ce que le serveur sp6cialis6 (12) est un serveur HTTP comportant 
une interface avec le protocole RADIUS. 

25 19. SystSsme selon Tune des revendications 12 ^ 18, 

caract6ris6 en ce que le contrdleur d'accfes (10) est un Proxy RADIUS. 

20. Systfeme selon Tune des revendications 12 k 19, 
caract^rise en ce que chaque acteur (6, 7, 8) du r&eau (5) comprend des moyens 

30 de stockage de cl6s secretes d'utilisateurs, des moyens pour d^erminer la 
donn6e d'authentification de I'utilisateur aupr^s de I'acteur en appliquant au 
nombre al6atoire repu dans une requSte d'authentification (46, 47) et k la cl6 
secrete d'un utilisateur I'algorithme pr^6fini, et pour comparer le r^sultat 
obtenu k la donn6e d'authentification de I'utilisateur repue dans la requSte 

35 d'authentification, I'utilisateur 6tant correctement authentifi6 par I'acteur 
uniquement si le r6sultat du calcul cryptographique obtenu est egal k la donn6e 
d'autlientification contenue dans la requSte d'authentification. 
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